home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20000824-20010305 / 000093_news@columbia.edu _Wed Oct 25 10:09:57 2000.msg < prev    next >
Internet Message Format  |  2020-01-01  |  6KB

  1. Return-Path: <news@columbia.edu>
  2. Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
  3.     by uhaligani.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA05445
  4.     for <kermit.misc@cpunix.cc.columbia.edu>; Wed, 25 Oct 2000 10:09:56 -0400 (EDT)
  5. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  6.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id KAA28245
  7.     for <kermit.misc@watsun.cc.columbia.edu>; Wed, 25 Oct 2000 10:09:56 -0400 (EDT)
  8. Received: (from news@localhost)
  9.     by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id JAA00278
  10.     for kermit.misc@watsun.cc.columbia.edu; Wed, 25 Oct 2000 09:50:22 -0400 (EDT)
  11. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  12. From: fdc@columbia.edu (Frank da Cruz)
  13. Subject: Re: log of a kermit comunication
  14. Date: 25 Oct 2000 13:50:20 GMT
  15. Organization: Columbia University
  16. Message-ID: <8t6oes$8j$1@newsmaster.cc.columbia.edu>
  17. To: kermit.misc@columbia.edu
  18.  
  19. In article <Pine.LNX.3.96.1001024185713.5485B-100000@atlanta.i2.com.br>,
  20. Luiz Geraldo Silva Braz  <braz@i2.com.br> wrote:
  21. :    
  22. :    This is a log of kermit comunication that I need to decode.
  23. :    The big questions are:
  24. :  
  25. :     1) What king of command could generate the first string
  26. :        sent to the kermit server?
  27. :        
  28. :              #A&  D#C"@%<ENTER> (see the log above)
  29. :  
  30. :     2) Would this entire comunication be the result of just
  31. :        one c-kermit command or a lot of commands? 
  32. :        What would be this (these) commands?
  33. :  
  34. :     I intend to create a script (using expect) to interact
  35. :     with c-kermit and automate this kind of comunication.
  36. :  
  37. :     I have inserted some coments (***) inside the log.
  38. :     
  39. :     Each set of packets has the sender ID ( "1>" to client and "0>"
  40. :     to the server) and two representations of the data sent in 2 
  41. :     columns.
  42. :     Some non-printbles caracteres are represented by "." at the 
  43. :     rigth column. In the left column appears the Hex code of each 
  44. :     char and the simbol of the non-printblesi char. 
  45. :     Thanks in advance.
  46. : Luiz Braz
  47. : braz@i2.com.br
  48. : PS: Sorry about the errors. This is the first message I have 
  49. :     wroten in English. :-) 
  50. : >-------------------------------------------------------------------------
  51. : *** Estabilishing the connection. 817371001 is just the phone number. :-)
  52. : 1> 0000: 41 54 44 54 30 77 30 33 31 38 31 37 33 37 31 30    ATDT0318173710
  53. :          A  T  D  T  0  w  0  3  1  8  1  7  3  7  1  0  
  54. :    0010: 30 31 0D                                           01.
  55. :          0  1  ^M 
  56. : 0> 0000: 0D 0A 43 4F 4E 4E 45 43 54 20 39 36 30 30 2F 41    ..CONNECT 9600/A
  57. :          ^M ^J C  O  N  N  E  C  T  bs 9  6  0  0  /  A  
  58. :    0010: 52 51 2F 56 33 32 2F 4C 41 50 4D 2F 56 34 32 42    RQ/V32/LAPM/V42B
  59. :          R  Q  /  V  3  2  /  L  A  P  M  /  V  4  2  B  
  60. :    0020: 49 53 0D 0A                                        IS..
  61. :          I  S  ^M ^J 
  62. This is the CONNECT message from the modem.
  63.  
  64. : 1> 0013: 23 41 26 20 20 44 23 43 22 40 25 0D                #A&  D#C"@%.
  65. :          #  A  &  bs bs D  #  C  "  @  %  ^M 
  66. The format of a Kermit packet is:
  67.  
  68.   MARK LEN SEQ TYPE DATA CHECK
  69.  
  70. Where:
  71.  
  72.   MARK  is a control character, Ctrl-A by default.
  73.   LEN   is a one-byte excess-32 length field.
  74.   SEQ   is a one-byte excess-32 sequence number.
  75.   TYPE  is a one-byte packet type.
  76.   DATA  is 0 or more bytes of data.
  77.   CHECK is the block check.
  78.  
  79. Let's assume that your protocol dump is printing Ctrl-A as "#A".  In
  80. that case:
  81.  
  82.   LEN   = '&' = ASCII 38 - 32 = 6.
  83.   SEQ   = ' ' = ASCII 32 = 32 = 0.
  84.   TYPE  = ' ' which is not a valid Kermit packet type.
  85.   DATA  = D#C"@
  86.   CHECK = %
  87.  
  88. So the MARK is wrong, the LEN is wrong, and the TYPE is wrong.  No Kermit
  89. program would recognize this as a valid packet.
  90.  
  91. If, however, the two spaces are a mistake of your recording tool, and really
  92. there is only one space, then we have:
  93.  
  94.   LEN   = '&' = ASCII 38 - 32 = 6.
  95.   SEQ   = ' ' = ASCII 32 = 32 = 0.
  96.   TYPE  = 'D' (Data)
  97.   DATA  = #C"@
  98.   CHECK = %
  99.  
  100. It's closer, but still the length is wrong (6 instead of 7).  But if we
  101. assume that #A is really Ctrl-A, then maybe #C really is Ctrl-C, in which
  102. case the length would be correct.  But the block check is still wrong.
  103.  
  104. : *** The server answers with an ack packet (Y) and a unknown M-package. 
  105. :     What kind of package is it? I did't see it at the kermit 
  106. :     protocol description I have?
  107. : 0> 0024: 23 41 25 20 20 59 2A 24 33 0D 23 41 53 20 5F 4D    #A%  Y*$3.#AS _M
  108. :          #  A  %  bs bs Y  *  $  3  ^M #  A  S  bs _  M  
  109. :
  110. This too has a superficial resemblence to a Kermit packet, if we assume that
  111. #A really is Ctrl-A and the two blanks are really one blank:
  112.  
  113.   LEN   = '%' = ASCII 37 - 32 = 5.
  114.   SEQ   = ' ' = ASCII 32 = 32 = 0.
  115.   TYPE  = 'Y' (ACK)
  116.   DATA+CHECK = *$#
  117.  
  118. But the block check isn't right, no matter how you interpret it.
  119.  
  120. [ ... and so on ... ]
  121.  
  122. : and the result of the command continues to come in sequences 
  123. : of three packages... (see the big questions I have made at the
  124. : begining of this mesage.) 
  125. There is some resemblence to Kermit protocol, but it isn't really Kermit
  126. protocol.  The proper sequence of messages is not there, the packets are not
  127. in the right format, the block checks are not correct.  And this is even
  128. allowing for some aftereffects of your recording tools.
  129.  
  130. - Frank